Votre recherche :

dump ps3

darkminuss
Re: HACK - La Playstation 3 hackée par Geohot
Lol zouu_zouu, je suis pas un nouveau, j'traine ici depuis 2008, c'est juste que j'aime pas poster, mais là ca m'a vraiment choqué l'irrespect que les gens ont envers ce mec.

Franchement, personnellement je prête pas aux conséquences de ce hack. Pourquoi? Tout simplement parce que pour l'instant, le seul truc qu'il a c'est un dump de sa Ram et de sa NAND, que personne ne pourra en faire autant, qu'il a utilisé du hardware et des softs qui ne sont certainement pas a la portée de tout le monde.

Bien sur je dis seulement, mais même si c'est ENORME, c'est pas ca qui vous apportera un ISO Loader Killeur de PS3 demain matin au réveil faut arrêter de penser à de telles sottises... Pour l'instant on en est au point qu'il se puisse qu'il y aie une faille dans la PS3, que celle ci soit exploitable, mais on est encore bien loin du super ISO Loader Killeur de PS3

Vous vous rendez pas compte, incultes que vous êtes du temps que ca à pris pour arriver a un hack "valable" de la Wii pour loader un jeu? Ayant été dans les premiers beta testeurs pour le backup launcher de Wii j'peut vous dire que ca a pris un max de temps pour arriver a un résultat quelque peut valide, et encore ca fait vraiment pas longtemps que c'est possible, un an et demi maximum... Alors imaginez la PS3, qui dont on a tant de mal a trouver une faille, subvienne subitement un ISO Loader de la mort qui tue... (xD) Vous avez encore de longs mois/années devant vous, faut pas vous en faire pour çà!

Alors arrêtez un peu de paniquer comme ca... x)
Voir le sujet
Pepecastil
Re : USB Loader GX : Support des disques durs NTFS
Bon pour le dump sur une partition de type FAT la rev r883 vient de sortir et corrige ça donc le dumpe est possible sur des partitions WBFS et FAT à partit de la r883. En revanche il semblerait que les partitions NTFS ne soient actuellement utilisées que pour la lecture seule et il me semble (je ne suis pas sûr) qu'il n'est actuellement pas prévu d'écrire (de dumper) un jeu sur une partition en NTFS.


Personnellement, je pense que ça pourrait être mis au point plus tard mais vu que mis à part windows(microsoft) la plupart des systèmes d'exploitation fonctionnent mieux sur du fat que sur du ntfs alors il va falloir sans doute être patient. Par exemple chez sony ils ont juste rendu la ps3 capable de lire du fat quand on branche un disque dur dessus, ils n'ont pas essayé de la rendre capable de gérer le ntfs.
Voir le sujet
Sabounette
Re: UPDATE - INFO ou INTOX - La première faille de la PlayStatio
mikratek Wrote:Mathieulh, tu dis qu'avec sa methode de dump les clefs de cryptage ne sont pas copier, mais si la PS3 n'est pas a meme de les verifier alors qu'elles soient presente ou pas sur le disc ne change pas grand chose non ?



Si je me trompe pas je croit que mathieulhdit que si la PS3 n'est plus a même de vérifier elle crash je me trompe peut être mais j'ai cru lire ça

EDIT oups je suis en retard
Voir le sujet
mathieulh
Re: UPDATE - INFO ou INTOX - La première faille de la PlayStatio
mikratek Wrote:Mathieulh, tu dis qu'avec sa methode de dump les clefs de cryptage ne sont pas copier, mais si la PS3 n'est pas a meme de les verifier alors qu'elles soient presente ou pas sur le disc ne change pas grand chose non ?



Les secteurs du disques sont encryptés, la ps3 a besoin d'une clé présente sur le disque original (mais non copiable avec du matériel standard) pour les décrypter, le problème c est que sur ton backup tu vas toujours avoir des secteurs encryptés mais il va te manque la clé sur le disque (cette dernière est unique par jeu), expliques moi comment la ps3 peut décrypter les secteurs sans la clé, ou même "ignorer" cette dernière ?
Voir le sujet
Mikratek
Re: UPDATE - INFO ou INTOX - La première faille de la PlayStatio
Mathieulh, tu dis qu'avec sa methode de dump les clefs de cryptage ne sont pas copier, mais si la PS3 n'est pas a meme de les verifier alors qu'elles soient presente ou pas sur le disc ne change pas grand chose non ?
Voir le sujet
hf206
Re: UPDATE - INFO ou INTOX - La première faille de la PlayStatio
Bonjour j'ai vu ca sur ultimate ps3 :

Voila un message de MathieuLH sur la partie forum d'un site concurent, pour info, Mathieulh etait quelqu'un de tres présent sur la Scène psp.Il s'est aussi interressé à la ps3. Enfin cest pas un idiot il sait de quoi il parle ;)

Alors d'une part, seuls 7 SPE sont utilisés, non pas 8, sur les 7 un des SPU est reservé non pas a lv1 (l'hypervisor) mais aux "loaders" en l'occurence pour les jeux, appldr

maintenant sache que lv2 (le kernel de la ps3) tourne par dessus lv1, cela signifie que si tu crash lv1, tu crash lv2, la ps3 va alors bipper (deux fois) et effectuer un hard reboot si tel est le cas)
Si un des loaders (isolated spu binary) est crashé, la console va alors crasher completement et seul l'utilisation du back switch pourras la faire redémarrer (le front pannel ne répondra plus)

Les sauvegardes sont vérifiées par lv2, non pas par l'hypervisor.

Le risque de lancer du code ppu non signé sur la console est inexistant, celui-ci étant verifié à la volée au préalable par le loader (la binary qui tourne en background au niveau de l'isolated spu)

Il est impossible en game mode de modifier la portion de la ram allouée à l'extérieur du jeu à cause notamment des LPAR, meme chose pour la lecture de cette dernière.

Compte tenu de la nature même de l'autentification du disque (appellée secure authentication) mettant en cause pas mal de variables telles qu'une clé unique par disque (utilisée en tant que seed), une encryption par secteur, et même un identifiant unique dans le sfo, swapper le disque comme cela est fait, fait figure de science fiction. Enfin sache que dumper un Bluray de jeu via linux ne sert a rien, le contenu du dossier USRDIR sera encrypté, (la clé pour décrypter ce contenu n'est bien sur pas présent dans le bluray copié), ce qui rend la lecture de cette copie d'autant plus impossible.

Il faut savoir que la plupart des secteurs du bluray sont encryptés (il ya une table qui défini quels secteurs ne sont pas encryptés, il est sous entendu pour la console que les secteurs non répertoriés sont encryptés), le probleme est que la décryption est effectuée de manière transparante par lv2, or lorsque l'on est sous otheros/linux, le kernel (généralement un kernel linux) tourne par dessus lv1 (tout comme lv2 le ferai s'il était lancé), comme lv2 n'est pas chargé, la décryption ne se produit pas.

Si vous voulez verifier ma "théorie", faites une image d'un disque via linux, et ouvrez l'EBOOT.BIN avec un éditeur hexadécimal, vous ne verrez que du garbage, alors qu'il est censé y avoir un self header (commençant par SCE en ASCII)

Le seul moyen d'avoir le vrai dump d'un disque est de lancer du code sur lv2, cela sous entend d'avoir un exploit adéquat ou une console de développement.


En gros, cette vidéo est un gros fake

P.S. Hadès c'est un dieu de la mythologie grecque, et ça ne se prononce pas du tout à l'anglaise.

Sur ce, je vous laisse à vos réflexions.
[/quote]
Voir le sujet
Leb2dud2
Re: INFO ou INTOX - La première faille de la PlayStation 3 décou
Mathieulh Wrote:Alors d'une part, seuls 7 SPE sont utilisés, non pas 8, sur les 7 un des SPU est reservé non pas a lv1 (l'hypervisor) mais aux "loaders" en l'occurence pour les jeux, appldr

maintenant sache que lv2 (le kernel de la ps3) tourne par dessus lv1, cela signifie que si tu crash lv1, tu crash lv2, la ps3 va alors bipper (deux fois) et effectuer un hard reboot si tel est le cas)
Si un des loaders (isolated spu binary) est crashé, la console va alors crasher completement et seul l'utilisation du back switch pourras la faire redémarrer (le front pannel ne répondra plus)

Les sauvegardes sont vérifiées par lv2, non pas par l'hypervisor.

Le risque de lancer du code ppu non signé sur la console est inexistant, celui-ci étant verifié à la volée au préalable par le loader (la binary qui tourne en background au niveau de l'isolated spu)

Il est impossible en game mode de modifier la portion de la ram allouée à l'extérieur du jeu à cause notamment des LPAR, meme chose pour la lecture de cette dernière.

Compte tenu de la nature même de l'autentification du disque (appellée secure authentication) mettant en cause pas mal de variables telles qu'une clé unique par disque (utilisée en tant que seed), une encryption par secteur, et même un identifiant unique dans le sfo, swapper le disque comme cela est fait, fait figure de science fiction. Enfin sache que dumper un Bluray de jeu via linux ne sert a rien, le contenu du dossier USRDIR sera encrypté, (la clé pour décrypter ce contenu n'est bien sur pas présent dans le bluray copié), ce qui rend la lecture de cette copie d'autant plus impossible.

Il faut savoir que la plupart des secteurs du bluray sont encryptés (il ya une table qui défini quels secteurs ne sont pas encryptés, il est sous entendu pour la console que les secteurs non répertoriés sont encryptés), le probleme est que la décryption est effectuée de manière transparante par lv2, or lorsque l'on est sous otheros/linux, le kernel (généralement un kernel linux) tourne par dessus lv1 (tout comme lv2 le ferai s'il était lancé), comme lv2 n'est pas chargé, la décryption ne se produit pas.

Si vous voulez verifier ma "théorie", faites une image d'un disque via linux, et ouvrez l'EBOOT.BIN avec un éditeur hexadécimal, vous ne verrez que du garbage, alors qu'il est censé y avoir un self header (commençant par SCE en ASCII)

Le seul moyen d'avoir le vrai dump d'un disque est de lancer du code sur lv2, cela sous entend d'avoir un exploit adéquat ou une console de développement.


En gros, cette vidéo est un gros fake

P.S. Hadès c'est un dieu de la mythologie grecque, et ça ne se prononce pas du tout à l'anglaise.

Sur ce, je vous laisse à vos réflexions.

J'aime bien tout ses commentaire qui explique des chose complexe qu'on comprend pas trop^^.
Par contre si on a une PS3 débug on peut ripper le BR.
Voir le sujet
Avatar de l’utilisateur
Tom Vivares
Re: UPDATE - INFO ou INTOX - La première faille de la PlayStatio
Pour ceux qui ont visiblement la flem de revenir en page 49 et de relire le tout.

Mathieulh Wrote:Alors d'une part, seuls 7 SPE sont utilisés, non pas 8, sur les 7 un des SPU est reservé non pas a lv1 (l'hypervisor) mais aux "loaders" en l'occurence pour les jeux, appldr

maintenant sache que lv2 (le kernel de la ps3) tourne par dessus lv1, cela signifie que si tu crash lv1, tu crash lv2, la ps3 va alors bipper (deux fois) et effectuer un hard reboot si tel est le cas)
Si un des loaders (isolated spu binary) est crashé, la console va alors crasher completement et seul l'utilisation du back switch pourras la faire redémarrer (le front pannel ne répondra plus)

Les sauvegardes sont vérifiées par lv2, non pas par l'hypervisor.

Le risque de lancer du code ppu non signé sur la console est inexistant, celui-ci étant verifié à la volée au préalable par le loader (la binary qui tourne en background au niveau de l'isolated spu)

Il est impossible en game mode de modifier la portion de la ram allouée à l'extérieur du jeu à cause notamment des LPAR, meme chose pour la lecture de cette dernière.

Compte tenu de la nature même de l'autentification du disque (appellée secure authentication) mettant en cause pas mal de variables telles qu'une clé unique par disque (utilisée en tant que seed), une encryption par secteur, et même un identifiant unique dans le sfo, swapper le disque comme cela est fait, fait figure de science fiction. Enfin sache que dumper un Bluray de jeu via linux ne sert a rien, le contenu du dossier USRDIR sera encrypté, (la clé pour décrypter ce contenu n'est bien sur pas présent dans le bluray copié), ce qui rend la lecture de cette copie d'autant plus impossible.

Il faut savoir que la plupart des secteurs du bluray sont encryptés (il ya une table qui défini quels secteurs ne sont pas encryptés, il est sous entendu pour la console que les secteurs non répertoriés sont encryptés), le probleme est que la décryption est effectuée de manière transparante par lv2, or lorsque l'on est sous otheros/linux, le kernel (généralement un kernel linux) tourne par dessus lv1 (tout comme lv2 le ferai s'il était lancé), comme lv2 n'est pas chargé, la décryption ne se produit pas.

Si vous voulez verifier ma "théorie", faites une image d'un disque via linux, et ouvrez l'EBOOT.BIN avec un éditeur hexadécimal, vous ne verrez que du garbage, alors qu'il est censé y avoir un self header (commençant par SCE en ASCII)

Le seul moyen d'avoir le vrai dump d'un disque est de lancer du code sur lv2, cela sous entend d'avoir un exploit adéquat ou une console de développement.


En gros, cette vidéo est un gros fake

P.S. Hadès c'est un dieu de la mythologie grecque, et ça ne se prononce pas du tout à l'anglaise.

Sur ce, je vous laisse à vos réflexions.


Ceci ne vous suffit pas? Pour rappel MatieuLh est un grand codeur et à étroitement travaillé avec D_A dans le domaine de la PSP, Wii, Iphone.

Si vous n'en faites qu'à votre tête en croyant un jeune lycéen le réveil sera alors brutal.

Comme un "bené" j'ais moi même tester sur une slim 3.15 avec un backup de fifia2008 et ceci ne marche pas. En j'en suis ravis. Pas de hack sur PS3 nous garantie la paix.

bref croyais ce que vous voulais mais je garantie que dans peux de temps la news informant au "fake" arrivera.
Voir le sujet
Avatar de l’utilisateur
goldbergg
Re: UPDATE - INFO ou INTOX - La première faille de la PlayStatio
Et bien et bien ^^"

felix vienne Wrote:la vidéo d'un certain "Ouriel" m'a laissé un doute. Pourrais t on avoir un peu plus d'information sur le "overflow" ? (peut être dans la prochaine vidéo)

un overflow est un dépassement de la mémoire tampont, sa ne resprésente pas un hack en soit, mais bien exploité sa peut le permétre, sa ma fait pensser a la premiére Downgrade de la PSP du 2.00 vers le 1.50 ou l'on devais justement utliser un overflow qui permété de lancer un bout de code qui fesait croire a la console qu'elle était en 1.00, le bon vieux temp....

Mathieulh Wrote:

Alors d'une part, seuls 7 SPE sont utilisés, non pas 8, sur les 7 un des SPU est reservé non pas a lv1 (l'hypervisor) mais aux "loaders" en l'occurence pour les jeux, appldr
[...]
Le seul moyen d'avoir le vrai dump d'un disque est de lancer du code sur lv2, cela sous entend d'avoir un exploit adéquat ou une console de développement.


En gros, cette vidéo est un gros fake

P.S. Hadès c'est un dieu de la mythologie grecque, et ça ne se prononce pas du tout à l'anglaise.

Sur ce, je vous laisse à vos réflexions.


Rain Wrote:
Peut etre Mathieulh raconte n'importe quoi du début à la fin aussi ^__^'

:)

et bien je ne suis pas aussi technique que Mathieulh et mes connaissance sont bien en dessous des siene mais
goldbergg Wrote:
Il a réussie a provoquer un overfow c'est bien, mais ca fais longtemp qu'on a réussie a en provoquer, que sa soit par le lecteur video, image ou depuis un jeux donc...

y a aussi un truc,
il dit que sur le 8iéme SPE se trouve l'hyperviseur, or j'ai toujours entendu que dans le modéle du CELL présent dans la PS3 le 8iéme SPE été griller a l'usine


goldbergg Wrote:Y a un truc que j'ai oublié de dire dans mes précédent post

j'avais aussi entendu dire que le lecteur bluray avais un cryptage, une signature qui permété de faire la diférence entre un BD Officiélle et un backup, et qu'en plus de devoire craker la PS3, il fallait craker le firmware de la PS3 pour lancer un BD non officiélle, y a pas d'autre connaisseur qui pourait me confirmé ???

c'est a peut prés se dont je parlé plus top dans la soiré ^^"

Sinon pour ceux qui parle de l'adresse MAC, pour ceux qui ne save pas se que c'est, c'est un numéro d'identification ecrie en hexa unique et propre a chaque carte réseaux, difuser sont adresse MAC n'est pas vraiment un probléme si sony la voix, difuser une video n'est pas un délie, et rien ne prouve qu'elle est vraix, toutefois masquer sont adresse mac(au niveaux logiciel) et la remplacer par une autre(celle du mec par exemple), dans certain cas sa peut être pratique |:D et la manip est tres simple sous Linux...
Voir le sujet
Avatar de l’utilisateur
MoMo 6o_1
Re: INFO ou INTOX - La première faille de la PlayStation 3 décou
Mathieulh Wrote:
Alors d'une part, seuls 7 SPE sont utilisés, non pas 8, sur les 7 un des SPU est reservé non pas a lv1 (l'hypervisor) mais aux "loaders" en l'occurence pour le jeux, appldr

maintenant sache que lv2 (le kernel de la ps3) tourne par dessus lv1, cela signifie que si tu crash lv1, tu crash lv2, la ps3 va alors bipper (deux fois) et effectuer un hard reboot si tel est le cas)
Si un des loaders (isolated spu binary) est crashé, la console va alors crasher completement et seul l'utilisation du back switch pourras la faire redémarrer (le front pannel ne répondra plus)

Les sauvegardes sont vérifiées par lv2, non pas par l'hypervisor.

Le risque de lancer du code ppu non signé sur la console est inexistant, celui-ci étant verifié à la volée au préalable par le loader (la binary qui tourne en background au niveau de l'isolated spu)

Il est impossible en game mode de modifier la portion de la ram allouée à l'extérieur du jeu à cause notamment des LPAR, meme chose pour la lecture de cette dernière.

Compte tenu de la nature même de l'autentification du disque (appellée secure authentication) mettant en cause pas mal de variables telles qu'une clé unique par disque (utilisée en tant que seed), une encryption par secteur, et même un identifiant unique dans le sfo, swapper le disque comme cela est fait, fait figure de science fiction. Enfin sache que dumper un Bluray de jeu via linux ne sert a rien, le contenu du dossier USRDIR sera encrypté, (la clé pour décrypter ce contenu n'est bien sur pas présent dans le bluray copié), ce qui rend la lecture de cette copie d'autant plus impossible.

Il faut savoir que la plupart des secteurs du bluray sont encryptés (il ya une table qui défini quels secteurs ne sont pas encryptés, il est sous entendu pour la console que les secteurs non répertoriés sont encryptés), le probleme est que la décryption est effectuée de manière transparante par lv2, or lorsque l'on est sous otheros/linux, le kernel (généralement un kernel linux) tourne par dessus lv1 (tout comme lv2 le ferai s'il était lancé), comme lv2 n'est pas chargé, la décryption ne se produit pas.

Si vous voulez verifier ma "théorie", faites une image d'un disque via linux, et ouvrez l'EBOOT.BIN avec un éditeur hexadécimal, vous ne verrez que du garbage, alors qu'il est censé y avoir un self header (commençant par SCE en ASCII)

Le seul moyen d'avoir le vrai dump d'un disque est de lancer du code sur lv2, cela sous entend d'avoir un exploit adéquat ou une console de développement.


En gros, cette vidéo est un gros fake

P.S. Hadès c'est un dieu de la mythologie grecque, et ça ne se prononce pas du tout à l'anglaise.

Sur ce, je vous laisse à vos réflexions.


Mon sauveur xD !!! Je n'attendait que sa, une personne qui sais de quoi elle parle !
Alors la chapeau, au moins c'est clair et net !
Voir le sujet
Derniers tests et previews
Tous les tests
Dernières actualités
Toutes les actualités